Eigentlich kennen Sie bereits alles, was Sie benötigen, um Ihre Software mit einem komfortablen Installer-Script zu versehen. Im folgenden widmen wir uns spezielleren Kommandos, die Ihrem Script den letzten Schliff geben.
Ich möchte diesen Kursteil in vier Punkte gliedern:
Und damit legen wir auch gleich los...
Bis jetzt sind wir davon ausgegangen, daß der Anwender unsere Sprache spricht, und haben uns nicht weiter um die Lokalisierung unseres Scripts gekümmert. Wollen Sie aber ein Produkt z.B. im Aminet veröffentlichen, so macht es freilich einen sehr guten Eindruck, wenn auch Anwender anderer Nationalität als der Ihren in ihrer jeweiligen Sprache durch die Installation geführt werden.
Diese Aufgabe teilen wir in zwei Teile, bedingt dadurch nämlich, daß nicht alle Ausgaben des Installers in unserem Script festlegbar sind, sondern dieser auch eigene Ausgaben macht (z.B. bei den Startup-Screens und den eingebauten Hilfe-Texten). Wir müssen also einerseits unser Script lokalisieren, andererseits dem Installer mitteilen, in welcher Sprache er mit dem User kommunizieren soll.
Widmen wir uns zunächst letzterem. Wie Sie wissen, ist das Betriebssystem ab OS2.1 lokalisiert, dies gilt auch für den Installer. Läuft er auf einer dieser Versionen, so übernimmt er die Sprache aus den Lokale-Prefs und setzt auch gleich die @language-Variable entsprechend. Hier haben wir also nichts zu tun.
Anders verhält es sich bei OS2.0. Hier müssen wir dem Installer die bevorzugte Sprache über den LANGUAGE-Tooltype (s. Tooltypes im ersten Kursteil) mitteilen. Dazu erstellt man am besten für jede Sprache ein separates Project-Icon, trägt im Default-Tool den Aufruf für das Script ein und setzt den LANGUAGE-Tooltype auf die entsprechende Sprache.
Da aber auch das OS2.0 Englischkenntnisse voraussetzt und heutzutage sowieso die Verbreitung von Betriebssystemen höherer Versionen recht groß ist, halte ich diese Methode für überflüssig und empfehle an ihrer statt, als Standardsprache Englisch zu wählen und im weiteren auf ein lokalisiertes Betriebssystem zu bauen.
Wenden wir uns also der Scriptlokalisierung zu. Zentrale Rolle spielt hierbei die @language-Variable. Aus ihr entnehmen wir die Sprache, die in den Lokale-Prefs eingestellt oder im LANGUAGE-Tooltype gesetzt wurde. Was nun folgt, ist recht einfach. Zunächst ersetzen wir alle Strings im Script durch Variablen (mit aussagekräftigen Bezeichnern). Dann weisen wir innerhalb einer vom Inhalt der @language-Variablen abhängigen Verzweigung diesen Variablen wieder die Strings zu. Dies sollte freilich gleich zu Beginn des Scripts geschehen. Schematisch dargestellt also in etwa:
;Dieser Block dient zum Definieren der Strings in der Standardsprache (set #s_willkommen "Welcome to the installation ....") (set #s_kopieren ".......") ;Dann, falls eine andere Sprache eingestellt, Neubelegung der ;String-Variablen in derselbigen (if (= @language "deutsch") ( (set #s_willkommen "Willkommen zur Installation ....") (set #s_kopieren ".......") ;...... ) ) ;...... ;Für jede Sprache also einen entsprechenden IF-THEN-Block.
Im eigentlichen Script dann z.B. ...
(message #s_willkommen)
Damit ist das Thema Lokalisierung auch schon abgehakt.
Wie ja bereits an mehreren Stellen erwähnt, läuft das Script abhängig vom gewählten User-Level ab. Die Auswahl des User-Levels erfolgt auf dem ersten Startup-Screen, die Wahlmöglichkeiten lassen sich durch die Tooltypes MINUSER und DEFUSER beeinflussen. Zu den Bedeutungen:
Im NOVICE-Modus werden die Rückfragen einiger Statements übergangen, so daß das Script im Idealfall abläuft, ohne daß der User eine Frage beantworten muß oder sonstwie damit konfrontiert wird. Auch die Ausgaben von (message ) werden hier unterdrückt, sofern kein (all)-Parameter gesetzt wird. Zur weiteren Beeinflussung dieses Modus beachten Sie jeweils die Befehlsbeschreibungen der entsprechenden Kommandos.
AVERAGE- und EXPERT-Modus funktionieren von Seiten des Installers gleich, sie müssen vom Scriptschreiber getrennt werden. Dies kann Beispielsweise mittels des (confirm)-Parameters einiger Statements geschehen, jedoch auch durch Abfragen der internen Variable @user-level. Diese enthält den User-Level als Zahlenwert 0 bis 2 mit 0 für NOVICE.
Weitere Informationen dazu finden Sie im ersten Teil dieses Kurses: Style-Guide, Tooltypes, Vordefinierte Variablen.
In diesem Zusammenhang möchte ich noch drei weitere Kommandos einführen. Diese sind (WELCOME ), (EXIT ) und (USER ).
Taucht das (WELCOME )-Statement in einem Script auf, so wartet der Installer mit dem Öffnen der Startup-Screens (Welcome-Screens) bis zu diesem Statement und führt erst alle Kommandos aus, die davor im Script auftauchen. Außerdem lassen sich zusätzliche Begrüßungs-Strings definieren.
Dank dieses Kommandos läßt sich ein wenig tricksen. Zusammen mit dem (EXIT )-Statement läßt sich das Auftauchen der Startup-Screens vollständig vermeiden, indem man das (WELCOME )-Statement hinter dem (EXIT )-Statement plaziert. Auf diese Weise bekommt der User gar keine Kontrolle über das User-Level und die weiteren Startup-Optionen. Eine andere Möglichkeit ist der Einbau von (WELCOME ) in eine Schleife, so daß die Auswahl immer wieder neu vorgenommen werden kann.
(EXIT ) beendet die Scriptausführung. Dies ist vor allem in Verzweigungen sinnvoll, um ein vorzeitiges Beenden realisierbar zu machen o.ä.
Mittels (USER ) läßt sich letztlich der User-Level modifizieren. Die Original-Styleguides veranlassen mich, Sie darauf hinzuweisen, daß dieses Kommando nur zu Testzwecken benutzt werden soll und in fertigen Scripts nicht mehr auftauchen soll. Dieser Hinweis ist sicherlich darauf zurückzuführen, daß ein gewisser Standard der User-Level erhalten werden soll und in den Scripts nicht wild dazwischen hin- und hergeschaltet wird, jedoch habe ich selbst die Erfahrung gemacht, daß es durchaus nützlich sein kann, für einzelne Statements den User-Level temporär runter- oder hochzusetzen um Einflußnahmen zu unterdrücken oder zu erlauben. Vergessen Sie dabei aber nicht, den User-Level vor dem Ändern in einer Variablen zu sichern, damit Sie ihn danach wieder herstellen können.
Obgleich der Installer eine eingebaute Fehlerkontrolle hat und somit bereits recht sicher funktioniert, kann es nötig werden, im Falle eines Fehlers weitere Schritte zu unternehmen, um nicht Überreste der Installationsprozedur zu hinterlassen. Zu diesem Zwecke existieren die Befehle (TRAP ), (ONERROR ) und (ABORT ).
Mittels (TRAP ) läßt sich die Ausführung von Statement-Folgen überwachen und bei Auftreten eines Fehlers die Ausführung mit den hinter dem (TRAP )- Statement kommenden Befehlen fortfahren (z.B. um bereits erstellte Verzeichnisse wieder zu entfernen etc.).
(ONERROR ) wird benutzt, um eine Statement-Folge zu definieren, die bei Auftreten eines (nicht von (TRAP ) abgefangenen) Fehlers abgearbeitet wird.
Diese Anweisungen sind vor den Script-Teilen, in denen die Fehler auftreten können, zu plazieren, also in der Regel am Scriptanfang.
(ABORT ) bricht die Ausführung des Scripts ab, wobei mit der Ausführung der mit (ONERROR ) definierten Statements fortgefahren wird. Evtl. angegebene Fehlermeldungen werden dabei dem User präsentiert.
In diesem Abschnitt seien auch noch die Befehle (DEBUG ) und (TRANSCRIPT ) untergebracht. (DEBUG ) ermöglicht es, Ausgaben in die Shell zu machen, von der aus das Script gestartet wurde, sofern dies der Fall war, (TRANSCRIPT ) dient dazu, beliebigen Text in das vom Installer ggf. angelegte Logfile zu schreiben.
Ein weiterer noch nicht näher angesprochener Punkt ist die Bitmanipulation. Einige der Befehle des Installers arbeiten mit Bitmasken, z.B. (ASKOPTIONS ). Deshalb ist es nötig, deren Funktionsweise zu verstehen und manchmal auch, sie von Hand zu manipulieren.
Zum Verständnis:
Eine Bitmaske ist nichts anderes, als eine Folge von Bits, die entweder gesetzt oder nicht gesetzt sein können. Dies läßt sich am einfachsten in binärer Schreibweise darstellen, eine Übertragung in das dezimale System kann aber auch sinnvoll werden.
Bsp.:
binäre Darstellung: 0 0 1 0 1 1 1 0 repräsentiert 2 hoch Nummer des Bits: 0 1 2 3 4 5 6 7 also: 1 2 4 8 16 32 64 128 ergibt als Summe: (0*1)+(0*2)+(1*4)+(0*8)+(1*16)+(1*32)+(1*64) (dezimale Darstellung:) +(0*128) = 4+16+32+64 = 116
Der dezimale Wert 116 repräsentiert also eineindeutig (116 führt bei Zerlegung in entsprechende Potenzen wieder genau zu der oben angegebenen binären Darstellung) die binäre Bitmaske 00101110.
Die Bitfolge wäre beliebig fortführbar. (ASKOPTIONS ) verwendet nun diese Bitmasken, um die Auswahl des Users zu repräsentieren. Dabei repräsentieren gesetzte Bits (1) gewählte Einträge.
ManipulationZum Beeinflussen von Bitmasken stehen z.B. sogenannte bitweise logische Funktionen, also Funktionen, die für jedes Bit der Maske die entsprechende logische Funktion durchführen, wie (BITAND ), (BITOR ), (BITXOR ) und (BITNOT ) zur Verfügung. Die logischen Funktionen von ARexx sind übrigens keine echten, sondern bitweise logische Funktionen.
Außerdem können alle Bits innerhalb der Maske verschoben werden. Dies geschieht mittels (SHIFTRIGHT ) bzw. (SHIFTLEFT ).
Zu guter letzt läßt sich noch prüfen, ob bestimmte Bits innerhalb einer Maske gesetzt sind, oder nicht, was durch die Funktion (IN ) geschieht. Diese wurde bereits im zweiten Kursteil beschrieben.
Details zu allen hier aufgeführten Kommandos finden Sie wie immer in den Befehlsbeschreibungen.
Sie kennen damit den gesamten Befehlsumfang, sowie die Verfahrensweise bei der Erstellung eines Installerscripts. Um Ihre Scripts übersichtlich zu gestalten, sollten Sie von den Prozeduren gebrauch machen, sie eignen sich nicht nur zum Sparen von Schreibarbeit, sondern auch zum Gliedern des Codes.
Manche Variablen lassen sich auch sparen, indem man ein wenig Anweisungen schachtelt, passen Sie dabei aber auf, daß Ihr Code nicht zu unübersichtlich wird, eine übersichtliche Scriptgestaltung erleichtert das spätere Hineinfinden erheblich.
Im nächsten Kursteil widmen wir uns vor allem ein paar zusätzlichen Tools, sowie inzwischen erschienenen alternativen Installern. Außerdem erhalten Sie dann eine Gesamtbefehlsübersicht als AmigaGuide-Datei.
|
Inhaltsverzeichnis | |
| © `99Der AmZeiger | ||